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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 

Abstract 


This document is the result of a survey asking people to detail their 
advanced usages of X.500. It is intended to show how various 
organizations are using X.500 in ways which extend the view of X.500 
as a "White Pages" service. This RFC is a product of the Integrated 
Directory Services Working Group of the Application and User Services 
Areas of the IETF. 


1. Introduction 


As the use of X.500 spreads in the Internet, organizations are 
finding uses for it which go beyond the "white pages" paradigm which 
has been used to introduce it to new users. Consequently, to document 
those new uses and to encourage the wider use of X.500, we sent out a 
survey to obtain "advanced usages" of X.500. 


1.1 The survey 


The survey we sent out is included here for two purposes: 
1) completeness, and 
2) we’d like to encourage anyone who retrieves this document to send 


us their advanced usage for inclusion in the next revision. 


If you wish to fill this out, please send it to the working group 
list: IDS@merit.edu. 
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Application Name: 

Author(s): 

Company or Institution: 

e-mail address for more information: 


If this is a product for public distribution, please give us the 
Type: FREE, COMMERCIAL PRODUCT, or PROTOTYPE/RESEARCH 
FREE - Anyone may obtain this product at zero cost. 
COMMERCIAL PRODUCT - One may purchase this product. 
PROTOTYPE/RESEARCH - This product is not yet available, only a 
prototype. 


If FREE, please give us: 
* FTP and/or FTAM address (if available via FTP and/or FTAM): 


If COMMERCIAL, please give us: 
* Directions to obtain product: 


Availability: (When will product be available?) 


List of platforms product runs on: 
[The platform list can be general - e.g. UNIX] 


Short Description (< 100 words): 
Full Description (< 1 page): 


Fig. 1: Advanced Usages Survey Template 


This survey went out to the following mailing lists: osi- 
ds@cs.ucl.ac.uk, disi@merit.edu (now ids@merit.edu), and 
dssig@ics.uci.edu. 
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1.2 Disclaimer 
Descriptions of the advanced usages were written by the implementors, 
and not by the members of IDS. Although IDS has worked with the 
description authors to ensure readability, no guarantees can be made 
regarding the validity of descriptions. Caveat emptor. 

2. The Survey Responses 


2.1 Index to Responses 


Application Page 


2.2.1 Global Time-table Information Service ................ 3 
2.2.2 Pre-Message Security Protocol ~~) ................ 4 
2.2.3 Electronic Data Interchange = ~~ ................ 5 
2.2.4 Network Topology Information = —  ................ 7 
2.2.4.1 Shared Whois Information Project  ................ 7 
2.2.4.2 EARN’s Network Directory =  — .....eeeeeeeeeee 8 
D260. SOL. Pages: = ~ lae s 8 i caidas a 9 
Zed XSTSL! 6 2 | aS ven tig a ghauee dete ts 10 
2.2.7 Xerox Clearinghouse = essesesessseseoo 12 
22208 Xes00- Sendmail 2 hee ctcehe ete Snake 13 
2.2.9 Transparent ODA Conversion = ~— ......-.......-- 14 
2.2.10 X.500 and the whois protocol ~~ ................ 16 
2.2.41 X400 table handling: < Hb eeemecd eee e oar ey Se 17 


2.2 Survey Responses 
2.2.1 Global Time-table Information Service 
Application Name: Global Time-table Information Service based on X.500 
Date Received: 7/1/1992 
Date Last Validated: 7/1/1992 
Author(s): 
Jens Hofmann 
Cuno Lanz 
Company or Institution: 
Laboratory of Computer Engineering and Networks, 
Swiss Federal Institute of Technology (ETH Zurich) 


Switzerland 


e-mail address for more information: 
c=CH; a=ARCOM; p=SWITCH; o=ETHZ; ou=TIK; s=Lanz (lanz@tik.ethz.ch) 
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Type: 
experimental prototype; not public 


FTP address: <none> 


Short Description: 
This application aims at integrating the time-table information 
services offered by public transport providers of different scope 
(local, regional, national or international) into a homogeneous and 
unified user interface. X.500 is used to store the information in 
an autonomous and extensible way. 


Full Description: 
Most of the public tranport providers offer some kind of time-table 
information service like printed directory, help-desk, telephone 
support or PC software. Unfortunately these services have some of 
the following drawbacks: 


—- no automatic update of data (information accuracy) 
- no global availability (place independency) 

- no permanent availability (time independency) 

- no inter-provider service (service integration). 


X.500 may serve as a vehicle to overcome these drawbacks as 
follows: The public transport providers store the time-table 
information in a standardized format on locally managed DSAs. There 
is some kind of special purpose DUA which (1) queries the user for 
the input parameters (date, time, source and destination station) 
then (2) searches for the relevant paths by querying the involved 
DSAs and (3) displays the resulting time-table to the user. 


In a diploma thesis a student is developing a new data model which 
supports easy selection of source and destination station as well 
as fast exploring of the time-table information. He is implementing 
a prototype application onto an existing DUA interface (based on 
HyperCard and running on Apple Macintosh) which is connected to the 
world-wide X.500 pilot service over DIXIE protocol. In order to 
test the prototype application the time-table information of the 
Swiss national public transport company and of most of the regional 
providers around the city of Zurich is included under the branch: 
c=CH;0=ETH Zurich. 


2.2.2 Pre-Message Security Protocol 


Application Name: 
Defense Message System Directory 


Date Recieved: 7/1/1992 
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Date Last Validated: 7/1/1992 


Author: 
Bob Cooney 


Company or Institution: 
The Naval Computer and Telecommunications Station, Washington 
and 
The Defense Information System Agency 


E-mail address for more information: 
cooney@wnyose.nctsw.navy.mil 


Type: 
experimental prototype, not public 


FTP address: <none> 


Short Description: 
The U.S. Navy will build a directory based on X.500 to support the 
distribution of Pre-Message Security Protocol security keys. 


Long Description: 
The U.S. Navy has been asked to build a directory service to support 
the distribution of Pre-Message Security Protocol security keys. 
The Pre-Message Security Protocol will provide SMTP/X.400 security 
services for unclassified but sensitive mail on the Defense Data 
Network. 


The directory will be based on QUIPU. Proof of concept is expected 
by October 1992, with initial operational capacity by October 1993. 


2.2.3 Electronic Data Interchange 
Application Name: An X.500 User Agent for Electronic Data Interchange 
Date Received: 7/10/1992 
Date Last Validated: 7/10/1992 


Author: 
Neil Weldon 


Company or Institution: 
Networks Group, 
Computer Science Dept., 
Trinity College Dublin, 
Ireland 
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e-mail address for more information: 
omahony@cs.tcd.ie 
nmweldon@vaxl.tcd.ie 


Type: 
Research product and not for public distribution 


FTP address: <none> 


Short Description: 
The Directory is used to assist in solving the ’first order’ 
problem associated with Electronic Data Interchange (EDI). EDI is 
the transfer of trade documents between application processes ina 
processable form. The ’first order’ problem describes the 
agreements that two organizations must come to regarding 
capabilities and preferences, before using EDI. 


To solve this problem we defined object types to allow the storage 
of product catalogues within the Directory, as well as information 
about the EDI readiness of trading partners: addresses, preferences 
and EDI capabilities. 


Full Description: 
Electronic Data Interchange (EDI) is the means by which 
organizations exchange trade related documents between application 
processes in an format which may be processed electronically. 


Before using EDI an organization must establish a series of goals 
and objectives, to establish what type of documents they wish to be 
able to transmit (invoices, purchase orders etc.) and what their 
communication requirements are. Each of these time consuming and 
tedious steps is usually done in conjunction with trading partners 
where these agreements regarding EDI capabilities and preferences 
must be made. 


To solve this ‘first order’ problem (the need to come to agreements 
with other organizations before trading using EDI takes place) we 
defined object types to allow the storage of product catalogues 
within the Directory. The Directory may also convey information 
regarding the EDI readiness of trading partners: addresses, 
preferences and EDI capabilities. 


Using an experimental User Agent based on Pod which was developed 
at Brunel in the UK, trade documents may be built up by selecting 
products from the stored catalogues. These documents are then 
encoded as an EDI Interchange after the Directory has been queried 
about addresses, etc. 
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The current object types are very basic and may only convey the 
minimal amount of information necessary. We are now in the process 
of extending this further to a full product class hierarchy which 
is being based on information that may be sent within an EDI trade 
document using the EDI standard document syntax EDIFACT. 


By using the Directory as a repository for product information to 
aid in EDI the catalogues become available worldwide. They may be 
replicated at various nodes, and the updating and propagation of 
changes to slave copies becomes trivial. 


2.2.4 Network Topology Information 


There are two projects in this area; Merit Network’s Shared Whois 
Information Project, and EARN’s Network Directory. 


2.2.4.1 Shared Whois Information Project 
Application Name: Shared Whois Project 
Date Received: 6/1/1993 
Date Last Validated: 6/1/1993 
Author(s): Sheri Repucci 
Company or Institution: Merit Network, Inc. 
e-mail address for more information: swip@merit.edu 


Availability: June 1993 


Type: 
experimental prototype, not public 


List of platforms product runs on: UNIX 


Short Description: 
The Shared Whois Project merges network data held by various 
organizations. The principal purpose of merging this data is to 
find and resolve conflicting network information between the 
databases. The longterm goal of this project is to move away from 
the current model of storing similar and/or duplicate network 
information in multiple databases and to move to a X.500 
distributed database model. To this end, we are working on loading 
the NSFNET network information into X.500 in anticipation of 
participating in a distributed database trial. 
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Full Description: 
The Shared Whois Project is a collection of programs and shell 
scripts which collectively merges the network data held by each of 
the participating organizations. Currently this includes Merit, 
the RIPE-NCC and the InterNIC. The principal purpose of merging 
this vast quantity of data is to find and resolve conflicting 
network information between the various databases. It is our 
intent to merge this data bi-weekly and thus rapidly reach, and 
thereafter maintain, a stable set of commonly held network 
information. 


While there is a common set of information all three of the 
participants hold in their various databases, additional 
information unique to the function of each organization is also 
held. Furthermore, the resulting set of data created by the merger 
holds only one entry per network without attempting to combine the 
variations. Thus, each entry includes a listing of all databases 
found to contain information for that network as well as all 
databases found to be in conflict with the entry held in the 
resultant set. 


The longterm goal of this project is to move away from the current 
model of storing similar and/or duplicate network information in 
multiple databases and to move to a X.500 distributed database 
model. To this end, Merit is working to load the NSFNET network 
information into X.500 in anticipation of participating in a trial 
with the InterNIC and others on the road to a globally distributed 
database model. 
2.2.4.2 EARN’s Network Directory 

Application Name: Ditnet/EARN Network Directory 

Date Received: 7/7/1992 

Date Last Verified: 7/7/1992 


Author(s): 
Peter Sylvester 


Company or Institution: 
Inria Rocquencourt - France 


e-mail address for more information: 
peter.sylvester@inria.fr 


Type: FREE (data owned by EARN/Bitnet) 
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Short Description: 
The EARN/Bitnet Network database consists of descriptions of all 
participating members, network nodes, adminstrators, and topology 
information. This database commonly known as BITEARN NODES is being 
made available through x.500. 


Full Description: 
A full description of the contents of the EARN/Bitnet database 
can be found in some EARN internal document which is available 
as a file BITEARN NODES from any NETSERV in EARN/Bitnet. The 
contents of this file is mapped into an X.500 subtree containing 
descriptions of network nodes, adminstrational personnel, and 
topology information. 


The first version of the directory subtree will be created using a 
simple textual mapping to a flat directory tree using private 
attributes. 


2.2.5 Soft Pages 
Application Name: Soft Pages 
Date Received: 9/25/1992 
Date Last Validated: 9/25/1992 
Author(s): 
Thomas Johannsen 
Glenn Mansfield 
Company or Institution: 
AIC Systems Laboratory, 


Tohoku University Sendai 


e-mail address for more information: 
spp-support@aic.co.jp 


Type: 
Intended for public distribution, not yet public 


FTP address: <none> 


Short Description: 
A file name look-up services for anonymous FTP servers, provides 1s 
-1R information and FTP server address. Additionally, the nearest 
FTP site (from user’s site) which holds the requested file is 
chosen. 
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Full Description: 
With the growing of number and size of electronic archives for 
documents, programs and the like, the problem of finding and 
retrieving a specific file becomes more and more complex. 
Furthermore, bandwidth in the Internet is still limited. Users 
should be encouraged and supported to do local FTP sessions as often 
as possible instead of getting everything from the other end of the 
world (i.e., the net). 


The Soft Pages Project combines an Archie-like file look-up service 
with network configuration knowledge. A dedicated User Agent gives 
a suggestion how to retrieve a document in a network traffic 
optimized manner. 


Basically, Directory information introduced by Soft Pages falls 
into two parts: A file information part and a network configuration 
part. 


The file information part describes objects and attributes for file 
servers and their contents. For each file server, names and 
attributes of its files are stored and updated periodically. This 
provides global access to Archie-like information for all 
registered file servers and, furthermore, opens the way to store 
document description together with the file name. Thus, document 
search is not restricted to file name matches but might be run for 
keywords as well. 


The network configuration part provides information on networks 
(subnetworks), nodes and lines in the Internet. Furthermore, IP 
numbers can be mapped to network and node objects. In order to 
evaluate file server sites, Internet (site to site) connections are 
given a cost index and then alternatives are compared by their cost 
index. Cost index is a calculated parameter representing properties 
of a connection like speed, average traffic, charges etc. where 
values for the latter are hold as attributes to line objects. 


If a document is stored at two or more sites, the site with the 
lowest cost index (which naturally will be the "nearest" in network 
terms) will be chosen for retrieval. A Soft Pages User Agent 
basically interacts with the Directory for finding a pointer to the 
"best" copy of a file wanted by a user. 

2.2.6 X-Tel 


Application Name: X-Tel’s advanced applications 


Date received: 7/1/1992 
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Date last verified: 7/1/1992 


Author(s): 
Colin Robbins 
Julian Onions 
Graeme Lunt 


Company or Institution: X-Tel Services Ltd. 


e-mail address for more information: 
x500@xtel.co.uk 


Type: 
Commercial Products / Ideas 


Short Description: 
1) Product Information. Products that have DUA facilites built in 
have a "latest info" button or other request method. When 
"pressed" a well known node below the X-Tel part of the tree is 
read. The attributes contain descriptions of the latest version of 
the software, new features etc. If you decide you would like the 
new version, a second read obtains the information required for a 
template order form. 


2) BUG Status. As above, but obtains details of known bugs in the 


version of software you are running. (If only we could find a way 
of putting fixes in, and automatically updating the software 
itself!) 


3) X-Terms. We have a conferencing product, allowing X users to 
"talk" and share windows. The problem is identifying which X 
Terminal device a particular user is currently on. One solution we 
are using is modify a users directory entry during login to say 
which X display they have logged into. The conference can the 
query the directory, and open windows on the appropriate device. 
The directory is also used to store details of current conferences, 
so new delegates can join the conference easily. 


4) Organisation browsing. There are a rich set of attributes about 
people and their roles stored in the directory. We have a special 
purpose DUA that exploits this information, and presents 
information on who manages who, who is secretary for who etc. This 
is very useful when combined with the search ACL mechanism defined 
in OSI-DS 21 as different views can be given to different 
catergories of users. 


5) MHS use of directory. The directory is use to store MHS routing 
information (as per the MHS DS working group documents) 
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6) Mail Lists. Details of mailing lists are stored in the 
directory. With careful use of access control, users can be given 
access so that they can subscribe and unsubscribe themselves 
to/from a list. 


7) Details of restuarants in the Nottingham area are stored in the 
directory! 


8) We plan to use the directory as a rendevuz for a multi-user 
adventure game. Each "room" will be a different entry, and modify 


operations will be used to pick up and put down objects! 


The next two are "advanced" features of our DUA, they may not be 
considered relevant to this document! 


9) Templates. The directory is used to store template entries. 
Our DUA then uses this template when adding new users. Very 
useful, as a number of default attributes can be set. 
10) Editors. Special purpose editors for a number of complex 
attribute syntaxes are built in to our DUAs. This includes QUIPU 
ACLs, and X.400 OR Addresses. 
2.2.7 Xerox Clearinghouse 

Application Name: Clearinghouse Interface 

Date Received: 7/1/1992 

Date Last Validated: 7/1/1992 


Author(s): 
Margaret Avino 


Company or Institution: 
Xerox Corporation 


e-mail address for more information 
mavin.cin_ops@xerox.com 


Type: 
Early Design/Implementation stages 


Short Description: 
X.500 DSA interface to XNS (Xerox Network Services) Clearinghouse 
directory to provide access to Xerox Corporation’s Clearinghouse via 
X.500 DUAs. 
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Full Description: 
Xerox uses the XNS network protocol suite to provide Mail, Filing, 
Directory, Authentication, etc. network services for the installed 
based of 45,000+ Xerox workstations. The Directory is based on the 
XNS Clearinghouse protocol which is similar to X.500 in that it 
contains objects which have properties (attributes) and is a fully 
distributed, replicatable directory. The searching capabilities of 
the Clearinghouse protocol are not as robust as the X.500 search 
operation and the physical structure of the original database is 
not amenable to complex searches as it could be if it were stored 
in a relational database. 


The first piece of this project is to transfer the data into an 
Oracle relational database and create a new Clearinghouse server 
which accesses the oracle database and is a full fledged member of 
the Clearinghouse, sending and receiving updates to other servers 
using the XNS Clearinghouse protocol. This will allow powerful SQL 
queries to be performed on the data which will provide some very 
desired functionality such as: list all of the Distribution Lists 
of which this name is a member. 


To build on the new database, we are probing the implementation of 
an X.500 DSA interface to the Oracle Clearinghouse Directory. This 
would allow X.500 DUAs to access the data and utilize the powerful 
search operations. It will require the definition of one or more 
new object classes and several new attributes and some thought 
about the appropriate schema. 
2.2.8 X.500 Sendmail 

Application Name: X.500 Sendmail 

Date Received: 9/25/1992 

Date Last Verified: 9/25/1992 


Author(s): 
Tim Howes 


Company or Institution: 
University of Michigan 


e-mail address for more information: 
x500@umich.edu 


Type: 
FREE 
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FTP address: terminator.cc.umich.edu 


Directions to obtain product: 
get x500/sendmail—-5.65.x500.tar.2Z 


Short Description: 
Modifications to sendmail-5.65 to do X.500 lookups. 


Full Description: 

We have modified sendmail-5.65 so that it does X.500 lookups, 
returning the value of a user’s rfc822Mailbox attribute. It 
handles multiple matches by sending a message containing the 
choices back to the sender. If the user has no email address in 
X.500, the sender is sent a message containing postal and phone 
information on the user. Both exact and approximate matching is 
supported. 


2.2.9 Transparent ODA Conversion 
Application Name: Transparent ODA Conversion 
Date Received: 7/16/1992 
Date Last Verified: 7/16/1992 


Author(s): 
MacFarland Hale (MITRE Open Systems Group) 


Company or Institution: 
The MITRE Corporation 


e-mail address for more information: 
machale@mitre.org 


Type: 
Not Yet Available 


Short Description: 
Plan to use X.500 in conjunction with X.400 and Open Document 


Architecture (ODA) to provide transparent translation of compound 


documents between a sender and one or more recipients. 


Full Description: 
In the future, MITRE would like to combine X.500, X.400 and Open 


Document Architecture (ODA) to automate the conversion of compound 
documents in such a way that the users need not know about ODA or 


even that the conversion is taking place. This will require new 
and/or updated X.400 products. 
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A preferred compound document format (e.g., Microsoft Word, 
FrameMaker, etc.) for each user is stored in the X.500 directory. 
Each X.400 Message Transfer Agent (MTA) host also houses converters 
between each such format and the Open Document Interchange Format 
(ODIF). 


A user (sender) creates a document with his or her preferred 
compound document editor. Ideally, the editor software will have a 
link (e.g., button or pull-down menu) to the X.400 User Agent (UA). 
The user invokes the X.400 UA (either using this link, or outside 
of the editor software) to send the document as an X.400 message to 
one or more recipients. Next, the document may need to be 
converted to ODIF, and this may be done in one of two ways. 


Preferably, the X.400 MTA will be responsible for the ODIF 
conversion. The UA must somehow be told what format the original 
document is in. This may be done via the UA invocation from inside 
the editor, via a UA configuration file, by examining the filename 
extension, etc. It then tags the document to indicate the 
document’s original format using one of the body parts: 
"Bilaterally Defined" (body part 14), "Nationally Defined" (body 
part 7) or "Externally Defined" (body part 15). The UA then sends 
the message, and the MTA interprets the tag to determine the 
document’s format. 


For messages internal to MITRE, the MTA will look up the 
recipient’s preferred document format. If it is different than the 
sender’s format, the MTA calls the appropriate ODIF converter and 
sends the message. If the recipient’s preferred format is the same 
as that of the document being sent, then no conversion is 
performed. For messages going outside MITRE, the document is 
always converted to ODIF. The user may prevent this by specifying 
that the enclosed document is not to be converted, in which case 
the UA simply sends the document in binary form with no special 
tag. 


Alternatively, the UA may do the conversion. As above, the UA must 
be told the document’s original format. The UA may then call the 
appropriate local ODIF converter, and then send the message. There 
are some disadvantages to this approach: 


1) ODIF converters must be purchased for and maintained on many 
more hosts; 


2) the document is always converted to ODIF (unless the UA 
accesses the directory, but...); 


3) conversion overhead could be traumatic on a small PC. 
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At each recipient host, the X.400 MTA catches the incoming message, 
recognizing the contents as ODIF. It then looks up the recipients’ 
preferred compound document formats, calls the appropriate 
converters to translate the contents, and then delivers the 
messages to the recipients. If the incoming message contains one 
of the format tags described above, then no conversion is performed 
(since the document is not in ODIF). 


Please note that MITRE is a not-for-profit organization. We will 
not produce commercial products to support this scenario, but we 
are anxious to encourage and work with companies interested in 
doing so. 


2.2.10 X.500 and the WHOIS protocol 
Application Name: Phone Book 
Date Received: 7/15/1992 
Date Last Verified: 7/15/1992 


Author(s): 
Steven Schoch 


Company or Institution: 
NASA Ames Research Center 


e-mail address for more information: 
schoch@sheba.arc.nasa.gov 


Type: 
FREE, see Steve 


Short Description: 
On-line edition of our phone book, using X.500 for storage and 
retrieval. 


Full Description: 
Phone Book is a user application which communicates using the 
Internet WHOIS protocol. It is listed in the Internet Resources 
Guide as such. The latest incarnation, however, does not make use 
of a flat file -- it gets information from a DUA that performs 
conversions between information received via DAP and the format that 
users expect to get back from our Phone Book queries. The change to 
X.500 has allowed us to supply additional data such as E-mail 
address which do not normally appear in the phone book. The fields 
supplied in response to a query include: 
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Name 

Telephone Number 

Mail Stop 

Office Number 

Organizational Affiliation (either a NASA organization code 
or a contractor name) 

E-mail address 


Queries may be made on any of the fields specified, with the office 
being divided into building and room components. A sample lookup 


might be: 


trident:297-->phbook yee 


Name Phone M/S Office Organization 

Arnold M. Yee 4-4315 258-6 N258/134 COMPSCICOR 

Cindy Yee 226-3 N226/105 CALSPAN 
cyee@ames.arc.nasa.gov 

David H. Yee 4-4106 213-8 N213/256 EEF 
david_yee@qmgate.arc.nasa.gov 

Dr. Helen M C. Yee 4-4769 202A-1 N202A/216 RF 

Harry Yee 4-6557 213-2 N213/101F EES 

Peter Edmond Yee 4-3812 233-18 N233/240 EDC 
yee@atlas.arc.nasa.gov 

Robert Yee 4-4122 T041-3 TA20/155 SFA 


robert_yee@qmgate.arc.nasa.gov 
2.2.11 X.400 table handling 

Application Name: X.400 table handling 
Date Received: 7/15/1992 
Date Last Verified: 7/15/1992 
Author(s): 

Julian Onions 

Colin Robbins 
Company or Institution: 

X-Tel Service Limited, 


Nottingham, England 


e-mail address for more information: 
jpo@xtel.co.uk 


Type: 
FREE, not yet available to the general public 
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Short Description: 
Implementation of the work of the IETF MHS-DS group. The goal is to 
put X.400 tables into X.500 in order to facilitate gateway and 
routing functions. 


Full Description: 
See the Internet drafts for MHS-DS. NASA Ames Research Center is 
participating in the testing and development of the next release of 
the PP message handling software. The latest update (alpha test) 
contains usage of X.500 by X.400 for RFC 822<->X.400 gatewaying, as 
well as hooks for X.400 intelligent routing. Use of X.500 to 
eliminate static tables will greatly improve the ability to 
maintain the information necessary for mail gatewaying and routing, 
while making it easier to keep this data current and well 
distributed. 


3. Security Considerations 

Security issues are not discussed in this memo. 
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